Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-075.TXT

Text File | 1992-06-04 | 44.3 KB | 1,231 lines

C.S.M.P. Digest             Sat, 09 May 92       Volume 1 : Issue 75

Today's Topics:

    Floating Windows
    MacTudor
    Dynamic INIT Loading
    Comm. Tbx/MacTCP?
    PAP - where is programming info?
    Memory Manager Problems & System 7.0.1?
    PLookupName weirdness
    Simple text engine needed
    Symantec/THINK C ftp site
    Pointers to struct and Objects


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Michael Graf)
Subject: Floating Windows
Date: 11 Mar 92 16:33:18 GMT
Organization: Australian Programming Centre (IBMA)

Can anyone point me in the correct direction for some information on how
to implement floating windows, as seen in 'tear-off' menus, various packages,
etc. etc. I cannot find (probably, as I have not looked in the correct
place) information on how to implement them, and what window definitions
are needed.

 Are there any special tricks, rules or warnings that anyone can give me
when trying to code these windows (Pascal) or locations where sample code
may be found ?

 Any help, advice or direction is most appreciated.
Thanx, in advance.....


**********************************************************************
Regards,
  Michael Graf                             ([e-mail])
**********************************************************************

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 12 Mar 92 11:12:44 GMT
Organization: Reed College, Portland OR


  [e-mail] (Michael Graf) writes:
. Are there any special tricks, rules or warnings that anyone can give me
. when trying to code these windows (Pascal) or locations where sample code
. may be found?

  I bring good news and bad news.

  First, the good news:
  Some introductory source code for handling floating windows is on
sumex-aim.stanford.edu. Actually, it is fairly advanced code, and can be
quickly integrated into an application if you like it.
  No special window definition functions are absolutely required, but they
are consistantly done with smaller than average title bars that are filled
with a different texture than your vanilla document window. Not hard.
  Once you have a window definition function, marking a floating window can
be as simple as putting a special constant into the windowKind field of the
WindowRecord, which the grafPtr or windowPtr just so happens to point to.

  Now, for the bad news:
  The Window Manager was never designed for this, and special routines must
be used in place of your favorite toolbox calls. In the replacement, one
does call the toolbox routines, of course.  However, one calls them as your
routines cope with a seemingly endless stream of special cases. One tries
to predetermine as much as possible, but that almost makes it harder.
  The aforementioned source code is not production quality by any means. I
would advise reconsidering floating windows seriously before diving in.  A
fair amount of grueling testing is required, complicated by the linked list
that represents the window hierarchy itself, the demonic hack that is known
as MultiFinder or the Process Manager, plus the subtle problem of debugging
window relationships with source and debug windows loitering around.
  In fact, nobody on this group seems to be satisfied with their code.
Personally, I gave up and just started to assume that everyone was using
MultiFinder and that desk accessories would always be in their own layer.
  There is source available as part of MacApp, the Think Class Library, and
my own class library, which has yet to be named. You are welcome to mine,
if you are using Think Pascal and you don't have a Radius Rocket.

    Theus
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 6 Apr 92 05:25:54 GMT

Has anyone out there gotten a floating window to work in a ResEdit
extension (RSSC)?  I followed all the sample code in ResEdit Complete
by Peter Alley and Carolyn Strange, but I get random and sporadic
crashes.  I would try to describe them here, but I can't see that
anyone would find that information useful.  In a nutshell: the floating
window has a 50% chance of appearing.  If it does appear, the system
takes events in the floating window fine, but crashes on MouseDown
events in the main window, and always crashes on close.  If the floating
window doesn't come up, any the system works OK until I go to close, then
crash.  Sometimes it crashes when I click in the content region of
my editor window.

When I say random crash, I mean *random*.  I don't think the same thing
has happened more than twice so far!  All different--all exciting. :-(

Has anyone at all got any sample code that successfully implements
any type of floating window for any resource editor in any language
and any development system at all?  At this point, I'll take whatever
I can get!

Thanks for any help at all.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Tom Verhoeff)
Date: 6 Apr 92 14:24:36 GMT
Organization: Eindhoven Univ. of Technology, The Netherlands

In article <scott.702537954@mcl> [e-mail] (Scott Bronson) writes:
>Has anyone out there gotten a floating window to work in a ResEdit
>extension (RSSC)?

Can someone please explain what FLOATING WINDOWS are?  I tried to find
out through Inside Macintosh X-Ref, but without success.  They are,
for instance, also mentioned in Inside Macintosh volume VI (top of p. 5-8):

    [When receiving a suspend event,] [y]our application should
    also hide any floating windows, selections, and so on.

Tom
- --
INTERNET: [e-mail]  /    Eindhoven University of Technology
VOICE: [phone]      /    Dept of Mathematics & Computing Science
FAX: [phone]       /    PO Box 513, NL-5600 MB Eindhoven, Netherlands

---------------------------

From: [e-mail] (Bill Stackhouse)
Subject: MacTudor
Date: 1 Apr 92 23:41:26 GMT
Organization: Informix Software, Inc.

What is the current status of MacTudor? Is there a phone number for the
publisher?

Thanks
Bill Stackhouse
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Doug McNought)
Organization: California Institute of Technology
Date: Thu, 2 Apr 1992 13:28:08 GMT

In article <[e-mail]> [e-mail] (Bill Stackhouse) writes:
>What is the current status of MacTudor? Is there a phone number for the
>publisher?

Wow! I hadn't heard of this! Henry XIII on a disk! When do we get the modern
version, MacWindsor?
:) ;) ;}

- --
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 2 Apr 92 15:05:34 GMT
Organization: Kalamazoo College

[e-mail] (Bill Stackhouse) writes:
>What is the current status of MacTudor? Is there a phone number for the
>publisher?
>
>Thanks
>Bill Stackhouse
>[e-mail]

MacTudor has been out of print for the last four hundred years,
unfortunately.  The last issue's feature articles were "Half-Timbre:
arbitrary frequencies with the Sound Manager," "Terminate those scuzzy
gables!", and "Source for the latest WDEF: Palladian windows."

There was some kind of MacTudor revival earlier this century, but it
never got very far off the ground.

Recently, someone in Anaheim started a magazine with a similar title;
the estate of Queen Mary I is investigating the trademark, I hear.
You can reach MacTutor at 714-777-1255, fax [phone], or
[e-mail].
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Huckabay Modeller Tate)
Date: 2 Apr 92 14:46:26 GMT
Organization: Penn State University

In article <[e-mail]>,
[e-mail] (Doug McNought) says:
>
>In article <[e-mail]> [e-mail] (Bill
>Stackhouse) writes:
>>What is the current status of MacTudor? Is there a phone number for the
>>publisher?
>
>Wow! I hadn't heard of this! Henry XIII on a disk! When do we get the modern
>version, MacWindsor?
>:) ;) ;}

Oh, MacWindsor isn't for North American distribution; it's the edition
they designed for European use -- based in Hannover.  ;-)

And the Scots have their own -- MacStewart.   ;-) ;-)

- -------
Christopher Tate        |  "Computer Science has more real-world
                        |   applications than rotisserie baseball."
[e-mail]    |
Bitnet:  CXT105@PSUVM   |       -- Ben Liblit, next-door neighbor

+++++++++++++++++++++++++++

From: [e-mail] (Chuq Von Rospach)
Date: 2 Apr 92 17:08:11 GMT
Organization: I is a writur

[e-mail] (Bill Stackhouse) writes:

>What is the current status of MacTudor?

I talked to Sir Harry Wellingham last week. MacTudor (which we all know is
the long-awaited architectural CAD program) is still in Beta test. They've
had an unfortunate setback recently, when testing showed that someone
accidentally swapped the doric and corinthian columns in the library, so
they're having to go back and re-digitize and do regression testing.

The current hope is to have the package on the shelves in Mid-June.

- --
            Chuq "IMHO" Von Rospach, Enterprise Products Support
            [e-mail] | GEnie:CHUQ & MAC.BIGOT | ALink:CHUQ
               Book Reviewer, Amazing Stories =+= Member, SFWA
           Editor, OtherRealms =+= #include <standard/disclaimer.h>

And lo, though I travel deep through the valley of the archetypes, I shall
fear no evil, for I know that the Great Overlord shall protect me in all my
endeavours, for no matter how stupid or trite I become, if I snuff it, He'll
be forced to fill the last 100 pages without his Hero.

(so what if I'm a day late?)

+++++++++++++++++++++++++++

From: [e-mail] (Bill Stackhouse)
Date: 2 Apr 92 21:00:41 GMT
Organization: Informix Software, Inc.

The new phone number for the company publishing MacTudor is
[phone]. The first issue will be out at the end of April
for the April/May issue. The person said that it will have the
same format which I hope means it will cover the same kind of
information in the same level of detail.

Bill Stackhouse
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 Apr 92 04:51:29 GMT
Organization: Adept Solutions

WOW!
All this energy over one typo.
;)
- --
- -----------------+--------------------------------------------------
Roy Lovejoy      | internet:  [e-mail]
Head RGB Guy     | AppleLink: adept
Adept Solutions  | CIS:       72447,1447

---------------------------

From: [e-mail] (Joe Zobkiw)
Subject: Dynamic INIT Loading
Date: 3 Apr 92 15:10:57 GMT
Organization: The World Public Access UNIX, Brookline, MA

Here is an idea I've had in the past that may or may not work as planned.

There are numerous times when I would like to load an INIT/Extension
without having to reboot my Macintosh. Now, I realize that some INITs
_depend_ on the fact that they are loading before the Finder has launched,
etc...but...wouldn't it be cool to be able to automatically load (and
maybe even unload) INITs dynamically?

If we could only put them in their own heap (that _looked_ like the system
heap to them)...hmmm...

Any ideas?


- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 6 Apr 1992 10:35:07 GMT

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>Here is an idea I've had in the past that may or may not work as planned.

May not.

>There are numerous times when I would like to load an INIT/Extension
>without having to reboot my Macintosh. Now, I realize that some INITs
>_depend_ on the fact that they are loading before the Finder has launched,
>etc...but...wouldn't it be cool to be able to automatically load (and
>maybe even unload) INITs dynamically?

Sure would be cool.

>If we could only put them in their own heap (that _looked_ like the system
>heap to them)...hmmm...

Doesn't help. Most INITs do their work by patching Traps. Under a MultiFinder
like environment, which is becoming more and more common, it is already
impossible to patch a trap for all applications in a portable way (or am I
mistaken about that ?). When it comes to removing trap patches, things get even
more ugly.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 6 Apr 1992 15:49:37 GMT


Maybe...someday ;)

- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 6 Apr 1992 10:35:07 GMT

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>Here is an idea I've had in the past that may or may not work as planned.

May not.

>There are numerous times when I would like to load an INIT/Extension
>without having to reboot my Macintosh. Now, I realize that some INITs
>_depend_ on the fact that they are loading before the Finder has launched,
>etc...but...wouldn't it be cool to be able to automatically load (and
>maybe even unload) INITs dynamically?

Sure would be cool.

>If we could only put them in their own heap (that _looked_ like the system
>heap to them)...hmmm...

Doesn't help. Most INITs do their work by patching Traps. Under a MultiFinder
like environment, which is becoming more and more common, it is already
impossible to patch a trap for all applications in a portable way (or am I
mistaken about that ?). When it comes to removing trap patches, things get even
more ugly.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 6 Apr 1992 15:49:37 GMT


Maybe...someday ;)

- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Patrick C Beard)
Date: 7 Apr 92 19:17:32 GMT
Organization: Berkeley Systems, Inc.

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
#Here is an idea I've had in the past that may or may not work as planned.
#
#There are numerous times when I would like to load an INIT/Extension
#without having to reboot my Macintosh. Now, I realize that some INITs
#_depend_ on the fact that they are loading before the Finder has launched,
#etc...but...wouldn't it be cool to be able to automatically load (and
#maybe even unload) INITs dynamically?
#
#If we could only put them in their own heap (that _looked_ like the system
#heap to them)...hmmm...
#
#Any ideas?
#
#
#--
#<--------------------------------------------------->
# joe zobkiw                     [e-mail]
# mac.synthesis.MIDI.development.C.asm.communications
#>---------------------------------------------------<


Watch out for my paper and talk coming up at MacHack this summer. I will
be discussing a technique for developing INIT's that lets you write them
as applications. The technique could easily be extended to load INIT's
dynamically. In fact, this  has been a dream of mine for some time.

If you can't attend MacHack, the code and paper will be available on the
CD-ROM.

I might event release early drafts of the paper to those who would feel
qualified to comment/criticize the techniques presented.

Patrick C. Beard
Berkeley Systems, Inc.

---------------------------

From: [e-mail]
Subject: Comm. Tbx/MacTCP?
Date: 3 Apr 92 15:51:16 GMT
Organization: Cornell University


     I am thinking about getting involved in some network programming on the
Mac, and was trying to figure out how MacTCP and the Communications Toolbox
fit together.  It seems to me that MacTCP should be implemented as a tool in
the Communications Toolbox, and I'm wondering why it isn't.  From my initial
reading, the 2 products seem to be unaware of each other.  Am I
misunderstanding how the different communications layers inter-relate?
Also, I'm wondering to what extent the Communications Toolbox is catching
on.  Are most new applications for which it is relevant using it, and if not
why not?  Thanks in advance for any comments.
Tim Dorcey
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 3 Apr 92 17:36:56 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] writes:
>fit together.  It seems to me that MacTCP should be implemented as a tool in
>the Communications Toolbox, and I'm wondering why it isn't.  From my initial
>reading, the 2 products seem to be unaware of each other.  Am I
>misunderstanding how the different communications layers inter-relate?

To some extent, yes.  MacTCP is at a lower level than the Comm Toolbox; it
can't (reasonably) be done as a Comm Tool.  However, if you ask "Why can't
most TCP connections be done with a Comm Toolbox Telnet Tool?" then you are
indeed asking a sensible question.

I can only answer for myself.  I do support the Comm Toolbox, but I also
do direct MacTCP connections.  There are two reasons why:

1) Abstraction.  Both the blessing and the curse of the CTB is that you
don't deal with the "guts" of your connection.  The positive side is that
you don't have to worry about those guts; you let the tool handle them.
The negative side is that you have little control over what's going on,
and little information about what's happening.  By going to MacTCP directly,
I have minute control over how things happen, and I can see exactly what
the problem is when things go wrong.

2) Cost.  There is no free telnet tool for the CTB.  Therefore, freeware
and shareware developers are reluctant to use such a tool, since they
can't be sure their users will have it.  MacTCP isn't free, but developers
can license it quite reasonably (IMHO), and everybody who wants to use
TCP/IP is going to have to have it anyway.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Dan Gerson)
Date: 8 Apr 92 22:49:43 GMT
Organization: Xerox PARC, Palo Alto, CA

In article <[e-mail]> [e-mail] (Steve Dorner) writes:

   To some extent, yes.  MacTCP is at a lower level than the Comm Toolbox; it
   can't (reasonably) be done as a Comm Tool.  However, if you ask "Why can't
   most TCP connections be done with a Comm Toolbox Telnet Tool?" then you are
   indeed asking a sensible question.

The MacX software from Apple comes with a MacTCP CTB tool, although it
isn't on the CTB distribution, and I believe that you are not legally
supposed to use it except with MacX.  In light of your comments about
MacTCP v.s. the CTB, I assume that the MacTCP tool implements only
simple connections.  But does anyone know what it actually does, and
what its real status (e.g. future) is?
- --

Dan Gerson                    [e-mail]
Xerox Palo Alto Research Center            415-494-4745
3333 Coyote Hill Road
Palo Alto, CA 94304
USA

+++++++++++++++++++++++++++

From: [e-mail] (Charlie Reiman)
Date: 9 Apr 92 00:22:53 GMT
Organization: University of Illinois at Urbana

[e-mail] (Dan Gerson) writes:

>In article <[e-mail]> [e-mail] (Steve Dorner) writes:

>   To some extent, yes.  MacTCP is at a lower level than the Comm Toolbox; it
>   can't (reasonably) be done as a Comm Tool.  However, if you ask "Why can't
>   most TCP connections be done with a Comm Toolbox Telnet Tool?" then you are
>   indeed asking a sensible question.

>The MacX software from Apple comes with a MacTCP CTB tool, although it
>isn't on the CTB distribution, and I believe that you are not legally
>supposed to use it except with MacX.  In light of your comments about
>MacTCP v.s. the CTB, I assume that the MacTCP tool implements only
>simple connections.  But does anyone know what it actually does, and
>what its real status (e.g. future) is?

The MacTCP tool is clearly label "For MacX only." This isn't just legal
hoodoo voodoo, it's a hard fact. If it were a _true_ MacTCP tool, you
would be able to specify the remote TCP port to connect to. With X
windows, the correct service port is 6000, which is hardcoded into the
tool (near as I can figure, anyway).

Unless you can type X graphics commands into your vt100 terminal tool,
the "MacTCP tool" is completely worthless for anything but MacX.

"MacTCP tool" is a terrribly misleading name. Had the authors named it
"MacX tool", much misunderstanding would have been avoided. You are not
the first person to claim the MacX tool is useful for something other
than X windows.
- --
Charlie Reiman - [e-mail]
"Reading USENET is like drinking from a firehose, you'll get very wet but
 you probably will still be thirsty." - Steve Steinberg

---------------------------

From: [e-mail] (Brain in Neutral)
Subject: PAP - where is programming info?
Date: 6 Apr 92 18:23:09 GMT
Organization: Cafe Limbo

What do I read to find out how to use Printer Access Protocol?
Inside Macintosh doesn't say much about it.  Inside AppleTalk (2nd
edition) discusses it at length, but from an abstract viewpoint (e.g.,
no data structure listings or function call prototypes).  I grepped
through my THINK C *.h files for "PAP" to no avail.


- --
Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (MrBadExample)
Date: 6 Apr 92 19:47:50 GMT
Organization: University of Illinois at Urbana

There are references to it in Programmer the LaserWriter and Programming with
AppleTalk...
- --
        "Language is a virus from Outer Space."
                    - William S. Burroughs

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Mon, 6 Apr 1992 21:21:51 GMT

In article <[e-mail]>, [e-mail]
(Brain in Neutral) writes:

> What do I read to find out how to use Printer Access Protocol?
> Inside Macintosh doesn't say much about it.  Inside AppleTalk (2nd
> edition) discusses it at length, but from an abstract viewpoint (e.g.,
> no data structure listings or function call prototypes).  I grepped
> through my THINK C *.h files for "PAP" to no avail.

There were several articles in the first and second year of MacTutor
that convered the programming interface.  Here's some C I recently
wrote that (klugily) calls them:


/* Printer Access Protocol (PAP) routines.
 * Note: there is one extra argument at the end of each argument list.
 * The actual call passes a pointer to the locked code and the assembly
 * (actually hex) code here pops it off and jumps to it.
 */

/* Open connection to PAP printer over the (appletalk) network.
 */
pascal OSErr PAPOpen(
    short *refnum,            /* PAP refnum returned here */
    char *printername,        /* NBP entity name of printer to open */
    short flowquantum,        /* Max data in flight (512 byte blocks) */
    struct papstatus *statusbuf,    /* Monitor status */
    short *compstate,        /* Monitor status */
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4E90                /* JSr    (A0)      ; Call at offset 0 */
};

/* Read a block of readback data from the printer.
 * Even though we don't look at the data we still must do this
 * lest the printer drive protocol hang on returning us data.
 * We are interested in the EOF because this means the last page got out.
 */
pascal OSErr PAPRead(
    short refnum,            /* PAP refnum */
    char *buffer,            /* Pointer to buffer for incoming data */
    short *length,            /* Length of data returned here */
    short *eof,            /* EOF flag returned here */
    short *compstate,        /* Monitor status */
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4EA8, 0x0004            /* JSr    4(A0)     ; Call at offset 4 */
};

/* Write a block of data to the printer
 */
pascal OSErr PAPWrite(
    short refnum,            /* PAP refnum */
    char *buffer,            /* Pointer to outgoing data */
    short length,            /* Length of outgoing data */
    short eof,            /* EOF flag */
    short *compstate,        /* Monitor status */
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4EA8, 0x0008            /* JSr    8(A0)     ; Call at offset 8 */
};

/* Asynchronously probe status of printer
 * (unused here, just included for completeness
 */
pascal OSErr PAPStatus(
    char *printername,        /* NBP entity name of printer to check */
    struct papstatus *statusbuf,    /* Monitor status */
    struct addrblock *netaddr,    /* "Hint"network address to try */
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4EA8, 0x000C            /* JSr    12(A0)    ; Call at offset 12 */
};

/* Close connection to the printer
 */
pascal OSErr PAPClose(
    short refnum,            /* PAP refnum */
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4EA8, 0x0010            /* JSr    16(A0)    ; Call at offset 16 */
};

/* Close all connections and prepare for unload of PAP code.
 */
pascal OSErr PAPUnload(
    Ptr papptr            /* Artifact of calling scheme */
       ) = {
    0x205F,                /* Move.L (A7)+,A0  ; Get pap pointer */
    0x4EA8, 0x0014            /* JSr    20(A0)    ; Call at offset 20 */
};


---------------------------

From: [e-mail] (Neil K. Guy)
Subject: Memory Manager Problems & System 7.0.1?
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Sun, 5 Apr 1992 19:41:12 GMT

 (apologies if this is an FAQ)

 Does anyone know if Apple has fixed the memory manager bug that affects
machines from the IIci on up? I have an INIT that supposedly fixes the
problem, but I was wondering if it's necessary with 7.0.1 or with the
new System 7 tuneups... thanks in advance!

 - Neil K. ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Brian Kendig)
Date: 6 Apr 92 20:03:28 GMT
Organization: Starfleet Academy, Princeton University

In article <[e-mail]> [e-mail] (Neil K. Guy) writes:
> Does anyone know if Apple has fixed the memory manager bug that affects
>machines from the IIci on up? I have an INIT that supposedly fixes the
>problem, but I was wondering if it's necessary with 7.0.1 or with the
>new System 7 tuneups... thanks in advance!

If you're talking about the "MMInit" to fix the memory hints bug in
the IIci and IIfx, DON'T USE IT.  Or, at least, be VERY careful when
using it -- while it can speed up your machine considerably, I've also
heard that it's not very stable at all and tends to do as much harm as
good by crashing your machine periodically.

Apple reportedly fixed this bug in System 7.0, so it's not needed if
you're running 7.0 or 7.0.1 with or without a Tune-Up.

     << Brian >>

- --
| Brian S. Kendig       --/\-- Tri     [e-mail], @PUCC
| Computer Science BSE  |/  \| Quad  You gave your life to become the person
| Princeton University  /____\ clubs    you are right now.  Was it worth it?

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 7 Apr 92 15:23:46 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@fraser.sfu.ca (Neil K. Guy) writes:

    Does anyone know if Apple has fixed the memory manager bug that affects
   machines from the IIci on up? I have an INIT that supposedly fixes the
   problem, but I was wondering if it's necessary with 7.0.1 or with the
   new System 7 tuneups... thanks in advance!

That INIT was a dirty hack i nthe first place...

No, it's not necessary with any sustem >= 7.0

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Glenn Austin)
Date: Tue, 7 Apr 92 14:03:39 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Neil K. Guy) writes:
>  (apologies if this is an FAQ)
>
>  Does anyone know if Apple has fixed the memory manager bug that affects
> machines from the IIci on up? I have an INIT that supposedly fixes the
> problem, but I was wondering if it's necessary with 7.0.1 or with the
> new System 7 tuneups... thanks in advance!

If you are talking about MM Init, I have one piece of advice for you:

  DON'T USE IT!!!

It was originally designed for use with 6.0.5 on the IIci, but was extremely
buggy, and was never supposed to have been released outside of Apple --
but someone let it out.

System 7.0 and later (and possibly 6.0.7/.8, but I haven't checked it out)
have fixes in place for the memory manager bug.

===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================

---------------------------

From: [e-mail] (Jerome Jahnke)
Subject: PLookupName weirdness
Date: 7 Apr 92 03:53:20 GMT
Organization: Biology Learning Center

I have been working on some AppleTalk stuff, and things are going along
smoothly until I was goofing with NBP and PLookupName. I get it all set
up and let PLookupName go to work. The Function PLookupName returns an
OSErr of 1. I could understand any error code less than 0. And would
hope for an error code of 0. But 1 is totally beyond what I expected.

I then decided to throw caution to the wind and NBPExtract what I was
getting back anyway. It all worked. It finds EVERYTHING it is supposed
to. So I am getting an unknown error code, but it looks like everything
is working just fine. Soooooo the question becomes. 1) Do I just fly fast
and loose and ignore any error 0 and above in PLookupName. OR 2) Do I have
a real problem, and should I keep digging. I have only run this on one
machine. It runs other stuff just fine (including the testNBP code from
one of the snippets packages).

Other particulars. I am writing this in C++ (but not MacApp). Using MPW's
C v3.2.1 and CFront v3.2d17. Hardware is a Mac IIfx using system 7 on
ethertalk.

Any help would be appreciated.

Jer,
- ----
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' or [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Tom Colley)
Date: 7 Apr 92 14:54:00 GMT
Organization: Pacer Software Inc., Westborough, MA USA

In article <[e-mail]> [e-mail] (Jerome Jahnke) writes:
>I have been working on some AppleTalk stuff, and things are going along
>smoothly until I was goofing with NBP and PLookupName. I get it all set
>up and let PLookupName go to work. The Function PLookupName returns an
>OSErr of 1. I could understand any error code less than 0. And would
>hope for an error code of 0. But 1 is totally beyond what I expected.
>...
>Jer,
>----
>Jerome Jahnke
>Biology Learning Center
>University of Arizona
>'[e-mail]' or [phone]

If you had said the ioResult field was 1, I would say it sounds as if you
are making an asynchronous call (async calls stuff a 1 into ioResult
until they complete).  But you said the function returns a 1.  It sounds
like you are assigning the result of a comparison instead of comparing the
assignment.

/* this will cause result to be 1 if PLookupName returns noErr */
if (result = PLookupName (pbptr, false) == noErr)
    printf ("%d\n", result);

/* this will work as desired, note the extra parens */
/*  v                                   v   */
if ((result = PLookupName (pbptr, false)) == noErr)
    printf ("%d\n", result);

The '==' has higher precedence than the '=', so result is getting
assigned the result of the compare (1 if equal, 0 if not).

Tom Colley
Pacer Software Inc.
<[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Jahnke)
Date: 7 Apr 92 19:08:05 GMT
Organization: Biology Learning Center

In article <[e-mail]>, [e-mail] (Tom Colley) writes:
> If you had said the ioResult field was 1, I would say it sounds as if you
> are making an asynchronous call (async calls stuff a 1 into ioResult
> until they complete).  But you said the function returns a 1.  It sounds
> like you are assigning the result of a comparison instead of comparing the
> assignment.
>

Much to my chagrin you are closer than you know. It was not quite what you
stated, but instead I this is what my code looked like:

     My Problem
         |
         v
TheErr = !PLookupName( &TheMPP, false );
if(TheErr != noErr)
     cout << "The Result of PLookup was: " << TheErr << "\n";

All I can say in my defense is it was late, I had too much caffine, space
aliens stole both my socks and my brain, ummmm the dog distracted me and the
cat typed it in. I don't know, but thanks all for you help. It is amazing
what a good nights sleep will do for you.

> Tom Colley
> Pacer Software Inc.
> <[e-mail]>

Jer,
- ----
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' or [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 8 Apr 92 17:34:36 GMT
Organization: The World Public Access UNIX, Brookline, MA

>> The Function PLookupName returns an OSErr of 1

Are you sure you initialized the variable that PLookupName is returning
it's OSErr into?






- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

---------------------------

From: [e-mail] (Ronald P. Smith)
Subject: Simple text engine needed
Organization: University of Illinois at Urbana
Date: Wed, 8 Apr 1992 00:54:30 GMT

I'm looking for a good text engine with no limit as to size of text.
I need to be able to display a 7 meg document in a scrolling window.  The
program would keep at most 100K in memory at a time, loading in a different
section of the text as needed.  I thought about writing something myself,
but don't really know where to start.  What is the accepted way to display
more than 32K of text in a window? Is it to re-write textedit using
quickdraw routines?  If anyone knows of a good, simple text engine I could
buy or could show me the light as to how to write something myself, I'd
greatly appreciate it.

p.s. For the meantime, all I need to do is to display 7 megs of selectable,non-
     wrappable text, but I'll need to add the capability to edit later also.

- --RS     Ron Smith ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 8 Apr 92 17:08:24 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.cso.uiuc.edu> [e-mail] (Ronald P. Smith) writes:

   I'm looking for a good text engine with no limit as to size of text.
   I need to be able to display a 7 meg document in a scrolling window.  The
   program would keep at most 100K in memory at a time, loading in a different
   section of the text as needed.  I thought about writing something myself,
   but don't really know where to start.  What is the accepted way to display

Welcome to the Number One Pet Peeve Of Mac Programmers (tm)

I would recommend the Word Solutions Engine from DataPak.
It's $394 per license, plus $1 for media (floppy) and the
license lets you use the library any way you want except
re-selling it as a library or in its "virgin" form.

It handles > 32k text, and they sell an add-on for paging
to disk (among other add-ons)

The functionality is a little quirkier than TextEdit, but
not much. I have had some problems with the selection not
updating correctly, but that's probably my own fault.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

---------------------------

From: [e-mail] (JASON HOLTZAPPLE)
Subject: Symantec/THINK C ftp site
Date: 7 Apr 92 19:10:27 GMT
Organization: Duke University; Durham, N.C.

I used to know of the existance of an ftp site containing THINK C
upgrades, snippets of code, etc. To my knowledge, it was the
"official" Symantec site. Could anyone with the ftp address
please post it to this newsgroup or email me directly?

Many thanks,
Jason Holtzapple



- --
 /----------------------------------------------------------------\
| Jason Holtz                            [e-mail]|
|       "And the knowledge that they fear is a weapon to be        |
 \ ********  used against them"  - The Weapon, 1982  ************ /

+++++++++++++++++++++++++++

From: [e-mail] (Thomas Alan Akins)
Organization: /local/lib/rn/organization
Date: Wed, 8 Apr 1992 04:26:21 GMT

In article <[e-mail]> [e-mail] (JASON HOLTZAPPLE) writes:
>I used to know of the existance of an ftp site containing THINK C
>upgrades, snippets of code, etc. To my knowledge, it was the
>"official" Symantec site. Could anyone with the ftp address
>please post it to this newsgroup or email me directly?
>
>Many thanks,
>Jason Holtzapple

ftp to ics.uci.edu
/mac/think-c


- --
*                                            Alan Akins                      *
*       "I could say 'addition'              [e-mail]            *
*        when I mean ... 'basketball.'"      University of Oregon            *
*                        - E. Tick           Department of Computer Science  *

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 8 Apr 92 14:30:38 GMT
Organization: Symantec Corp.

>>>>> On 8 Apr 92 04:26:21 GMT, [e-mail] (Thomas Alan Akins) said:

 > In article <[e-mail]> [e-mail] (JASON HOLTZAPPLE) writes:
>>I used to know of the existance of an ftp site containing THINK C
>>upgrades, snippets of code, etc. To my knowledge, it was the
>>"official" Symantec site. Could anyone with the ftp address
>>please post it to this newsgroup or email me directly?

 > ftp to ics.uci.edu
 > /mac/think-c

Just a minor clarification -- the ftp site at ics.uci.edu is not an
official Symantec ftp site. It does contain the latest updates and a
bunch of source code examples, however.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Kevin Hill)
Subject: Pointers to struct and Objects
Organization: Crash TimeSharing, El Cajon, CA
Date: Wed, 08 Apr 1992 06:09:46 GMT

  I am currently programming a CDocument Object...  However, I have about 15-20 panes in the document, that get created in BuildWindow.  My problem is this,

   I have created a structure that looks something like this.

   struct a{
    CPaneBorder    *border;
    CStaticText    *title;
    union {
        CStaticText    edit;
        CEditText    edit1;
        CDateText    date;
        CPhoneText    phone;
        }b;
    int    type;
    };

In the instance variables for the Document object, I declare struct a  *tracker;  The big problem comes when try to allocate memory for it.

  for(i = -; i < 9; i++)


       track[i] = (struct a)NewPtr(sizeof(struct a));

  the compiler does not seem to like that...
   oh yes, the (struct a) should be (struct a*), sorry.

  anyone have any ideas?
 -Kevin

   Also, is there a  limit to the number of objects CDocument can have?
 -Kevin Hill


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 8 Apr 1992 13:40:42 GMT

[e-mail] (Kevin Hill) writes:
>
>I am currently programming a CDocument Object...
>However, I have about 15-20 panes in the document,
>that get created in BuildWindow.

My two cents' of advice, first.  Create all the panes inside one big
pane, that's the first penny.  That way, your document will have an
itsMainPane, so it will be happy.  If you ever want to paint the
background behind these panes, or move them all, or something, it'll be
easier if you have one big pane that contains them.

The second penny is, keeping track of the individual panes is already
done for you with the main pane's itsSubViews instance variable.  You
don't need to create an array to get to them;  you can just FindItem()
on the list.  Before you allocate an array of these things, check out
CPane's Contains() method and make sure you know how to use CCluster's
search methods.  You should only need an array for the individual panes
if you really need instant access to them, and if they're arranged in
some repetitive fashion.

Now on to this problem...

>   I have created a structure that looks something like this.
>
>   struct a{
>    CPaneBorder    *border;
>    CStaticText    *title;
>    union {
>        CStaticText    edit;
>        CEditText    edit1;
>        CDateText    date;
>        CPhoneText    phone;
>        }b;
>    int    type;
>    };

I assume you means "CStaticText *edit", etc.  You can't declare an
variable of an object type, only a pointer to it.

>In the instance variables for the Document object, I declare
>struct a  *tracker;
>The big problem comes when try to allocate memory for it.
>
>  for(i = -; i < 9; i++)
>
>
>       track[i] = (struct a*)NewPtr(sizeof(struct a));
>
>  the compiler does not seem to like that...

If you define track as a pointer to (struct a), then track[i] is not a
pointer, it's the structure itself.  You probably want an array of
pointers to structures:  "struct a *track[10]" or somesuch.

Like I said, I wouldn't advise using this particular data structure...

>   Also, is there a  limit to the number of objects CDocument can have?

However much memory you have...
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Almost all portables today employ passive-matrix LCDs, and no one expects
 active-matrix screens to be cost-competitive for a few years" -PC World 2/92

---------------------------

End of C.S.M.P. Digest
**********************